System and Method for Translating Software Code

ABSTRACT

A system and method for generating test code software utilized by a test system for testing a circuit card assembly is provided. A translator provides an automatic translation of a test code from a first computer language to a second computer language. One or more pinmap documents are provided to map the pins of the circuit card assembly.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

The invention described herein was made in the performance of officialduties by employees of the Department of the Navy and may bemanufactured, used, licensed by or for the United States Government forany governmental purpose without payment of any royalties thereon.

BACKGROUND AND SUMMARY

The present disclosure relates generally to a system and method fortranslating software code from one language to another language. Moreparticularly, the present disclosure relates to a system and method forgenerating test code software utilized by a test machine for testing acircuit card assembly.

In commercial and military industries, test systems are often used totest various electrical equipment and electronics, such as circuitboards, hard drives, electrical components, semiconductors, integratedcircuits, and other electrical hardware and devices. These test systems,also referred to as automated test equipment, automatically performtests on a device based on instructions from test program software. Whena legacy test system is replaced by a new test system, the test programrun by the legacy test system must be converted to a language and formatthat is compatible with the new test system.

According to one illustrated embodiment of the present disclosure, asoftware translation method comprises receiving a first software codecontaining a first function command and data associated with the firstfunction command, the first function command being configured to producea first result, and associating at least one second function command ina second software code with the first function command. The methodfurther comprises generating a third software code based on the firstsoftware code, the generating step including creating a hybrid functioncommand based on the first function command, the hybrid function commandincluding an interface to the at least one second function command ofthe second software code, and creating a case statement configured toassociate the first function command of the first software code with thehybrid function command and to provide the data associated with thefirst function command to the hybrid function command, the hybridfunction command being configured to produce the same first result asthe first function command upon execution of the hybrid function commandusing the data associated with the first function command of the firstsoftware code provided by the case statement.

In one illustrated embodiment, the first software code is a test codeutilized by a first test system for performing an operational test on acircuit card assembly and the second and third software codes are testcodes utilized by a second test system for performing the operationaltest on the circuit card assembly. In one illustrated embodiment, thefirst result produced by the first function command and the hybridfunction command includes at least one test operation of the operationaltest on the circuit card assembly.

In one illustrated embodiment, the second software code is an instrumentcode file configured to interact with testing instruments of the secondtest system to execute the at least one test operation on the circuitcard assembly. In one illustrated embodiment, the associating stepincludes identifying at least one second function command in the secondsoftware code that is configured to cause the testing instruments of thesecond test system to perform at least a portion of the at least onetest operation on the circuit card assembly. In another illustratedembodiment, the data associated with the first function includes theidentification of at least one pin of the circuit card assembly, the atleast one test operation being performed on the at least one pin of thecircuit card assembly.

According to another illustrated embodiment of the present disclosure, amethod of generating test code software utilized by a processor of atest machine for testing a circuit card is provided, the circuit cardincluding a plurality of pins configured to connect to correspondingchannels of the test machine. The method comprises receiving at leastone input parameter, the at least one input parameter including a pinconfiguration of a circuit card, receiving a first test code referencingthe pins of the circuit card in a first identification format,translating the first test code to generate a second test code, thesecond test code referencing the pins of the circuit card in a naturalidentification format not recognizable by the processor of the testmachine, and associating each pin reference in the naturalidentification format with a pin reference in a second identificationformat based on the pin configuration of the circuit card, the secondidentification format being readable by the processor of the testmachine.

In one illustrated embodiment, the associating step includes creating afirst pinmap mapping each pin reference in the natural identificationformat to a corresponding pin reference in the second identificationformat. In one illustrated embodiment, the first pinmap maps thelocations of an input pin, an output pin, and a power pin of the circuitcard to the corresponding pin references in the second identificationformat. In another illustrated embodiment, each corresponding pinreference in the second identification format identifies a channel ofthe test machine connected to the pin of the circuit card identified bythe corresponding pin reference in the natural identification format.

In one illustrated embodiment, the method further comprises generating asecond pinmap based on the pin configuration of the circuit card and thechannel configuration of the test machine, the second pinmap associatingat least one channel of the test machine with a pin reference in a thirdidentification format. In another illustrated embodiment, the testmachine includes a graphical display configured to display the pinreferences in the third identification format based on the secondpinmap.

According to yet another illustrated embodiment of the presentdisclosure, a software translation system comprises a first softwarecode containing a first function command and data associated with thefirst function command, the first function command being configured toproduce a first result, a second software code containing at least onesecond function command, and a translator configured to receive thefirst software code and to generate a third software code based on thefirst software code. The third software code includes a hybrid functioncommand including an interface to the at least one second functioncommand of the second software code. The third software code furtherincludes a case statement associating the first function command of thefirst software code with the hybrid function command and beingconfigured to provide the data associated with the first functioncommand to the hybrid function command. The hybrid function command isconfigured to produce the same first result as the first functioncommand upon execution of the hybrid function command using the dataassociated with the first function command of the first software codeprovided by the case statement.

According to yet another illustrated embodiment of the presentdisclosure, a test code generation system configured to generate testcode software utilized by a processor of a test machine for testing acircuit card is provided, the circuit card including a plurality of pinsconfigured to connect to corresponding channels of the test machine. Thesystem comprises at least one input parameter identifying a pinconfiguration of a circuit card, a first test code referencing the pinsof the circuit card in a first identification format, and a translatorconfigured to receive the first test code and the at least one inputparameter and to generate a second test code based on the first testcode. The second test code references the pins of the circuit card in anatural identification format not recognizable by the processor of thetest machine. The system further comprises a first pinmap mapping eachpin reference in the natural identification format with a pin referencein a second identification format based on the pin configuration of thecircuit card, the second identification format being readable by theprocessor of the test machine.

Additional features and advantages of the present invention will becomeapparent to those skilled in the art upon consideration of the followingdetailed description of illustrative embodiments exemplifying the bestmode of carrying out the invention as presently perceived.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of thisinvention will become more readily appreciated as the same become betterunderstood by reference to the following detailed description when takenin conjunction with the accompanying drawings.

FIG. 1 illustrates an exemplary circuit card assembly configured to betested by a test system;

FIG. 2 is a block diagram illustrating a software translator receiving afirst test code and outputting a second test code;

FIG. 2A illustrates an exemplary portion of the first test code of FIG.2;

FIGS. 2B and 2C illustrate exemplary portions of the second test code ofFIG. 2;

FIG. 3 is a flowchart illustrating an exemplary method of translating asoftware code from a first language to a second language;

FIG. 4 is a flowchart illustrating an exemplary method of mapping thepins of the circuit card assembly of FIG. 1;

FIG. 4A illustrates an exemplary portion of a first pinmap document ofFIG. 4;

FIG. 4B illustrates an exemplary portion of a second pinmap document ofFIG. 4;

FIG. 5 is a flowchart illustrating an exemplary test code generationprocess according to one embodiment;

FIG. 6 is a flowchart illustrating an exemplary method for receivinginput settings in the test code generation process of FIG. 5;

FIG. 7 is a flowchart illustrating an exemplary software translationmethod in the test code generation process of FIG. 5;

FIG. 8 is a flowchart illustrating a comma identification routine of thesoftware translation method of FIG. 7;

FIG. 9 is a flowchart illustrating a check function routine of thesoftware translation method of FIG. 7;

FIG. 10 is a flowchart illustrating a close parenthesis routine of thesoftware translation method of FIG. 7;

FIG. 11 is a flowchart illustrating a check pattern routine of thesoftware translation method of FIG. 7;

FIG. 12 is a flowchart illustrating an open bracket routine of thesoftware translation method of FIG. 7;

FIGS. 13 and 13A are flowcharts illustrating a switch routine of thesoftware translation method of FIG. 7;

FIG. 14 is a flowchart illustrating a close bracket routine of thesoftware translation method of FIG. 7;

FIG. 15 is a flowchart illustrating a set routine of the softwaretranslation method of FIG. 7; and

FIG. 16 is a flowchart illustrating a space or tab routine of thesoftware translation method of FIG. 7.

Corresponding reference characters indicate corresponding partsthroughout the several views. Although the drawings representembodiments of various features and components in the presentdisclosure, the drawings are not necessarily to scale and certainfeatures may be exaggerated in order to better illustrate and explainthe present disclosure. The exemplification set out herein illustratesembodiments of the disclosure, and such exemplifications are not to beconstrued as limiting the scope of the invention in any manner.

DETAILED DESCRIPTION OF THE DRAWINGS

For the purposes of promoting an understanding of the principles of theinvention, reference will now be made to the embodiments illustrated inthe drawings, which are described below. The embodiments disclosed beloware not intended to be exhaustive or limit the invention to the preciseform disclosed in the following detailed description. Rather, theembodiments are chosen and described so that others skilled in the artmay utilize their teachings. It will be understood that no limitation ofthe scope of the invention is thereby intended. The invention includesany alterations and further modifications in the illustrated devices anddescribed methods and further applications of the principles of theinvention which would normally occur to one skilled in the art to whichthe invention relates.

Referring initially to FIG. 1, an exemplary circuit card assembly 20 ofthe present disclosure is shown. Circuit card assembly 20 is configuredto connect to electronic equipment 10 and to perform various functionsfor electronic equipment 10. Electronic equipment 10 illustrativelyincludes a backplane connector 12 having one or more slots 14, and eachslot 14 is configured to receive a circuit card assembly 20. Circuitcard assembly 20 and electronic equipment 10 may be used in a variety ofapplications, including manufacturing, military, or aerospaceapplications. In one embodiment, electronic equipment 10 is a radarsystem that utilizes a plurality of circuit card assemblies 20, eachcircuit card assembly 20 being configured to perform one or morespecific functions for the radar system. For example, circuit cardassembly 20 may read the memory of a computer on electronic equipment10, perform mathematical functions, monitor faults, perform memorycontrol functions, analyze data, and send control and configurationsignals to other equipment.

Circuit card assembly 20 includes a plurality of electrical components22 mounted to a circuit board 24. Components 22 include integratedcircuits (IC's), passive elements, and/or active elements. In theillustrated embodiment, circuit card assembly 20 is a digital card usedin a digital radar system, although circuit card assembly 20 mayalternatively be an analog card.

Circuit card assembly 20 includes one or more connectors 16 having aplurality of electrical pins 18. Pins 18 illustratively include inputpins, output pins, power pins, and a clock pin. Connector 16 may be anyconventional male or female connector configured to interconnect thecircuitry mounted to circuit card assembly 20 to a plug-in circuit cardassembly apparatus, such as backplane connector 12 of electronicequipment 10. Circuit board 24 of circuit card assembly 20 furtherincludes conductive paths (not shown) interconnecting components 22 toeach other and to pins 18 of connector 16. The conductive paths may beetched into a non-conductive substrate to facilitate communicationbetween components 22. The conductive paths may also be wire-wrapped.Circuit card assembly 20 may include any number of circuit boards 24,and each circuit board 24 may include any suitable number of layers tosupport the conductive paths.

A test system 30 illustratively includes a computer 34 and a userinterface 32. In the illustrated embodiment, test system 30 is a digitaltest system configured to perform operational tests on digital circuitcards 20 by running a series of test patterns on the circuitry of thecircuit cards 20. Test system 30 may also be configured to performanalog, mixed-signal, or serial bus testing on circuit cards 20. Eachtest pattern may include several test operations. Test system 30illustratively includes testing instruments 40 configured to executeeach test operation on the circuit card assembly 20. For example,testing instruments 40 may include signal generators, output detectors,and other instruments suitable for testing a circuit. Test system 30 isconfigured to test the functionality of circuit card assembly 20 and todetermine the existence of any faults, errors, and other failures ofcircuit card assembly 20. For example, test system 30 may be used totest a circuit card assembly 20 that has failed in the field or that hasbeen newly manufactured prior to entering the field.

Computer 34 of test system 30 includes a processor that executessoftware code, illustratively test system software 60 of FIG. 2, storedin a memory to perform an operational test on circuit card assembly 20,as described herein. User interface 32 allows an operator to provideinput settings to initiate the test program. User interface 32 mayinclude a graphical display to allow an operator to monitor the statusand results of the circuit card tests. A backplane connector 36 on testsystem 30 includes one or more adaptors 38 for receiving a circuit cardassembly 20. Each adaptor 38 includes a connector (not shown) configuredto receive a plug-in connector 16 of a circuit card assembly 20. Eachadaptor 38 routes pins 18 of circuit card assembly 20 to the appropriatepins of test system 30. In one embodiment, test system 30 is a modularsystem configured to receive various components for individualizedapplications. For example, test system 30 may further include one ormore power supplies and an oscilloscope. An exemplary test system 30 isthe Spectrum 9100 Series Model available from Teradyne, Inc.

Each circuit card assembly 20 has a corresponding software test codethat is loaded into test system 30 and executed by test system 30 inconjunction with software 60 to perform an operational test on eachcircuit card assembly 20. When a legacy test system is replaced by a newtest system, illustratively test system 30, the software code used bythe legacy test system to perform tests on each circuit card assembly 20is often not compatible with the processor of the new test system. Inmany instances, the software code utilized by the legacy test system iswritten in a computer language that is not readable by the new testsystem. In such a case, the software code must be translated into acomputer language readable by the new test system prior to executing thesoftware code and performing a test on the new test system.

As illustrated in FIG. 2, a translator 52 provides an automatictranslation of a first test code 50 to a second test code 54. In theillustrated embodiment, first test code 50 is utilized by a legacy testsystem, and second test code 54 is utilized by a new test system,illustratively test system 30. An exemplary portion of first test code50 is illustrated in FIG. 2A, and exemplary portions of second test code54 are illustrated in FIGS. 2B and 2C. In the illustrated embodiment,first test code 50 is written in Raytheon Test Language (RTL) and secondtest code 54 is written in C Programming Language. However, the firstand second languages may be other suitable programming languages. In theillustrated embodiment, translator 52 is an executable computer programstored on a computer separate from test system 30. Alternatively,translator 52 may be stored on computer 34 of test system 30 to allow auser to translate first test code 50 and to compile and execute secondtest code 54 on a single computer 34.

Translator 52 illustratively receives input settings 58 prior toperforming the software code translation, as illustrated in FIG. 2.Input settings 58 provide translator 52 with necessary informationregarding the translation to be performed. In the illustratedembodiment, input settings 58 include information regarding the pinconfiguration of circuit card assembly 20, as described herein withreference to FIGS. 5 and 6.

Second test code 54 may include one or more program or code files. Inthe illustrated embodiment, test code 54 includes a project file, aworkspace file, one or more header files, and one or more main files, asdescribed herein with reference to FIG. 5. In one embodiment, test code54 also includes one or more template files, such as template files 153and 155 of FIG. 5. Template files 153 and 155 are software codetemplates configured to receive program code manually input by a user orautomatically input by another program or system following thetranslation by translator 52. For example, when first test code 50includes additional program files written in a language not recognizedby translator 52, one or more template files may be created and used astemplates for a subsequent translation of the unrecognized programfiles. In one embodiment, template files 153 and 155 are called by otherprogram files of second test code 54 during the execution of the testpatterns on test system 30. In the illustrated embodiment, translator 52also generates documentation 56 utilized by test system 30.Documentation 56 may include one or more pinmap documents utilized bytest system 30, such as first pinmap document 114 and second pinmapdocument 116 of FIGS. 4, 4A, 4B, and 5. Documentation 56 may alsoinclude a “readme file” containing information regarding second testcode 54 and the translation process, such as readme file 159 of FIG. 5.

Each operational test performed by test system 30 detects faults, ifany, in the circuitry of circuit card assembly 20 by running a series oftest patterns on circuit card assembly 20. Each test pattern may includeseveral test operations, such as setting an input pin “high” anddetecting the output of a corresponding output pin, for example. In someinstances, thousands of test patterns are run during a single test ofcircuit card assembly 20. The test patterns provide an input signal toone or more input pins of circuit card assembly 20 and verify that aproper responsive output signal is detected at one or more output pinsof circuit card assembly 20. Test system 30 may isolate a fault oncircuit card assembly 20 by monitoring the output signals from theoutput pins over several executed test patterns. The test patterns areillustratively contained in second test code 54 and test system software60 and run by computer 34 of test system 30. In one embodiment, secondtest code 54 includes several test routines, such as test routine 63 ofFIG. 2B for example, and each test routine contains several testpatterns.

In the illustrated embodiment, upon loading test code 54 into computer34, test code 54 interfaces with an instrument driver, i.e., aninstrument code file, contained in test system software 60 to executethe test patterns on circuit card assembly 20. In particular, a set offunctions contained in an instrument file of software 60 and configuredto control the testing instruments 40 of test system 30 are called bytest code 54. The functions contained in software 60 allow test code 54to interact with the testing instruments 40 or hardware of test system30 that are used to physically run test patterns on circuit cardassembly 20. For example, the functions of software 60 are used to set apin of circuit card assembly 20 during the execution of a designatedtest pattern, to create conditions on each test pattern such as repeat,test, loop, halt, etc., to add new test patterns to the operational testof circuit card assembly 20, to fetch the state of an output pin ofcircuit card assembly 20 (e.g. high, low, or neither), to create a testroutine, and to run a test routine. Such a programming structure allowstest code 54 to use the pre-defined instrument driver functions storedin an instrument file at test system 30 rather than creating newinstrument driver functions in test code 54.

Referring to FIG. 3, an exemplary method of translating a software codefrom a first language to a second language using translator 52 isprovided. While the following describes FIG. 3 with reference to firsttest code 50, second test code 54, and test system software 60 of FIG.2, the method illustrated in FIG. 3 may be used to translate softwarecode not utilized by a test system. In block 70, translator 52 receivesfirst test code 50 written in a first language, such as RTL for example.First test code 50 is loaded into translator 52 from a data storagemedium or from a computer memory. A first function in first test code 50and the data associated with the first function are identified, asrepresented by block 72. In the illustrated embodiment, the firstfunctions in first test code 50 are configured to execute a testoperation or a test pattern. An exemplary first function is “LO”function 57 of first test code 50 illustrated in FIG. 2A. Otherexemplary first functions include the “HI”, “TOG”, and “XX” functions offirst test code 50. The data or argument value associated with eachfirst function is also identified at block 72. For example, the value125 associated with the “LO” function 57 in FIG. 2A is identified atblock 72.

At block 74 of FIG. 3, one or more second functions contained in testsystem software 60 of FIG. 2 are identified and associated with eachfirst function of test code 50. In particular, the intended testoperation of the first function identified at block 72 is examined. Oneor more second functions of software 60 are selected that are configuredto apply the intended test operation of the first function to theoperational test of circuit card assembly 20 using test system 30. Inthe illustrated embodiment, the second functions of test system software60 comprise the instrument file containing software code configured tocontrol the testing instruments and hardware of test system 30. Forexample, if a first function of test code 50 sets a pin of circuit cardassembly 20 to a “high” state, a second function of software 60 that isconfigured to cause test system 30 to set a pin of circuit card assembly20 to the “high” state is selected at block 74. In one embodiment, asecond function of test system software 60 is selected at block 74 thatis configured to cause the testing instruments of test system 30 toperform only a portion of the intended test operation of the firstfunction of test code 50 on circuit card assembly 20.

At block 76, a hybrid function is created based on the first function oftest code 50 identified at block 72. See, for example, exemplary hybridfunctions 62 and 64 of FIG. 2C. The hybrid function is written in asecond language readable by computer 34 of test system 30 (e.g. Clanguage) and is configured to perform the same task or to produce thesame result as the first function of test code 50. For example, if thefirst function of test code 50 provides a test pattern to theoperational test of circuit card assembly 20, a hybrid function iscreated at block 76 that is configured to provide that same testpattern. The hybrid function created in block 76 also includes aninterface to the one or more second functions of software 60 identifiedin block 74. In the illustrated embodiment, the hybrid function containsa function call to the one or more second functions of software 60identified in block 74. See, for example, function call 65 in hybridfunction 62 of FIG. 2C that interfaces second function“terM9_setChannelPinOpcode” of software 60 with hybrid function 62. Thecomplete testing operation or test pattern as defined by the firstfunction of test code 50 is performed at test system 30 using the hybridfunction. As represented by block 78, the hybrid function is stored in aprogram file. In the illustrated embodiment, a plurality of hybridfunctions, each corresponding to a first function of first test code 50and calling one or more appropriate second functions of software 60 (asdetermined at block 74), are stored in a single program file, such asfunctions file 147 of FIG. 5. In one embodiment, functions file 147 isreceived by translator 52 and is included in second test code 54generated by translator 52.

In one embodiment, the steps in blocks 72, 74, 76, and 78 are performedby a programmer manually before proceeding with the automatictranslation process using translator 52 at block 80. For example, thehybrid function may be written manually by a programmer upon analysis ofthe intended result of the first function of first test code 50, theoperation of the second function of test system software 60, and theadditional code in the hybrid function needed to achieve the intendedresult of the first function upon execution of the hybrid function attest system 30. Alternatively, the hybrid function may be createdautomatically using an algorithm stored in translator 52.

As represented by block 80, second test code 54 is generated in a secondlanguage (e.g. C language) based on a translation of first test code 50.The translation of first test code 50 to second test code 54 at block 80is described herein with reference to FIGS. 5-16. The generation ofsecond test code 54 includes the creation of a case statementcorresponding to the first function of first test code 50 identified inblock 72, as represented by block 82. The case statement associates thefirst function of test code 50 with the hybrid function of test code 54,as represented by block 84. The case statement also provides the dataassociated with the first function of test code 50 to the correspondinghybrid function of test code 54, as represented by block 86. As such,the case statement provides a function call to the hybrid function, andthe hybrid function is executed using the data provided by the casestatement. For example, a case statement 61 of the exemplary portion oftest code 54 in FIG. 2B associates the “LO” function 57 of exemplarytest code 50 of FIG. 2A with the hybrid function 64 of FIG. 2C. Further,case statement 61 provides the data “125” associated with the “LO”function 57 to hybrid function 64. At block 88, the case statement isstored in a program file of test code 54, such as patterns file 145 ofFIG. 5. In the illustrated embodiment, a plurality of case statementseach corresponding to a first function of test code 50 are created andstored in a program file of test code 54.

Referring to FIG. 4, an exemplary method of mapping pins of circuit cardassembly 20 is illustrated. In the illustrated embodiment, first testcode 50, second test code 54, and test system software 60 all referencethe pins of circuit card assembly 20 using a different identificationformat or nomenclature. In one embodiment, at least one of first testcode 50, second test code 54, and test system software 60 references thepins of circuit card assembly 20 using a different computer language. Inthe illustrated embodiment, one or more pinmap documents are created tocross-reference the pin references in each software code.

In the illustrated embodiment, software 60 references a pin of circuitcard assembly 20 by identifying the corresponding channel or pin ofadaptor 38 that is in communication with that pin of circuit cardassembly 20. The channels of adapter 38 of test system 30 do not alwayscorrespond to the pin numbers of circuit card assembly 20 on aone-to-one basis. For example, pin five on circuit card assembly 20 maymatch up with pin twenty-five on adaptor 38 of test system 30 whencircuit card assembly 20 is inserted into an adaptor 38 of test system30. As such, a pinmap document is created to map each pin of circuitcard assembly 20 to a corresponding channel of adaptor 38. See, forexample, second pinmap document 116 illustrated in FIG. 4 and describedherein. The pinmap document is utilized by test system 30 to accuratelydisplay the status of each pin on circuit card assembly 20 to userinterface 32. For example, test system 30 uses a pinmap document toreport the status of pin five of circuit card assembly 20 to userinterface 32 rather than erroneously reporting the status of the pin oncircuit card assembly 20 that is in communication with the fifth pin orchannel of adaptor 38.

Referring to block 100 of FIG. 4, translator 52 receives the pinconfiguration of the circuit card assembly 20 to be tested by testsystem 30. The pin configuration identifies the number of pins oncircuit card assembly 20 and may provide additional pin information suchas the locations of the input pins, the output pins, the power pins, theclock pin, and the tri-state pins. In the illustrated embodiment, thepin configuration is included in input settings 58 illustrated in FIG.2. An exemplary method of receiving the pin configuration is illustratedin FIG. 6 and described herein.

At block 102, first test code 50 is received by translator 52. Firsttest code 50 contains references to the pins of circuit card assembly 20in a first identification format. In the illustrated embodiment, thepins of circuit card assembly 20 are referenced in first test code 50using numerical values. Referring to FIG. 2A, for example, the number“125” in function 57 of test code 50 is used to reference a specific pinon circuit card assembly 20. As such, the location of each pin oncircuit card assembly 20 is identified in first test code 50 using acorresponding number value. Alternatively, the pin references of firsttest code 50 may include other suitable letters, numbers, or charactersthat are consistent with and recognizable by the programming language offirst test code 50.

At block 104, translator 52 generates second test code 54 that containsreferences to the pins of circuit card assembly 20 written in a naturallanguage identification format. The generation of second test code 54 bytranslator 52 is illustrated in FIGS. 5-16 and described herein. In theillustrated embodiment, the natural language pin references in secondtest code 54 are configured to be readable and recognizable by a userbut unreadable by computer 34 of test system 30. See, for example, thepin reference “P125” of case statement 61 of second test code 54illustrated in FIG. 2B. In the illustrated embodiment, test systemsoftware 60 is unable to recognize “P125” as a pin name, but a userreviewing second test code 54 may immediately associate “P125” with pin125 of circuit card assembly 20.

Software 60 contains pin references written in a second identificationformat or nomenclature. At block 106, a first pinmap document 114 isgenerated that associates each pin reference of second test code 54written in the natural identification format with a pin reference oftest system software 60 written in the second identification format. Inparticular, first pinmap document 114 maps the natural language pinreferences of second test code 54 to the pin references of test systemsoftware 60 written in the second identification format. See, forexample, exemplary portion 90 of first pinmap document 114 illustratedin FIG. 4A. Referring to line 91, the “P3” reference utilized by secondtest code 54 is mapped to the pin reference “TERM9_SCOPE_CHAN(3)”utilized by test system software 60. In the illustrated embodiment, thepin references utilized by test system software 60 identify thecorresponding channels of adaptor 38 that are in communication with thepins of circuit card assembly 20. Based on the pin configuration inputat block 100, first pinmap document 114 maps the locations of the inputpins, the output pins, the power pins, etc. of circuit card assembly 20to the pin references of test system software 60. In one embodiment,first pinmap document 114 is a program header file of second test code54 that is loaded into test system 30. As represented by block 108,second test code 54 is interfaced with software 60 using first pinmapdocument 114.

User interface 32 of test system 30 identifies and displays the pins ofcircuit card assembly 20 using a third identification format ornomenclature. At block 110 of FIG. 4, a second pinmap document 116 isgenerated that associates each channel of test system 30 with a pinreference written in the third identification format utilized by userinterface 32. As described above, second pinmap document 116 is utilizedby computer 34 to accurately report and display the status of each pinon circuit card assembly 20 to user interface 32, as represented byblock 112 of FIG. 4. Second pinmap document 116 may also define the databuses associated with the channels of test system 30. In the illustratedembodiment, second pinmap document 116 is a comma separated value (.csv)file that contains all the pin names and bus definitions for second testcode 54 that runs on test system 30. Referring to exemplary portion 92of second pinmap document 116 illustrated in FIG. 4B, Channel 68 of testsystem 30 is mapped to pin reference “C64_P198” and bus “XFRMSN2”. Uponloading second pinmap document 116 into test system 30, pin reference“C64_P198”, rather than “Channel 68”, is displayed by user interface 32when reporting the status of pin 198 of circuit card assembly 20 to auser.

Referring to FIGS. 5-16, an exemplary method of translating a programsource code from one language to another is provided. The translationmethod of FIGS. 5-16 is illustratively employed by translator 52 of FIG.2. In the illustrated embodiment of FIGS. 5-16, second test code 54,written in C language, is generated based on a translation of first testcode 50, written in Raytheon Test Language (“RTL”). In addition,documentation 56 of FIG. 2 is generated according to the translationmethod illustrated in FIGS. 5-16.

As represented by block 130 of FIG. 5, translator 52 first receivesinput settings and parameters from a user to aid in the translation.FIG. 6 provides a detailed flowchart illustrating an exemplary processof receiving input settings. In blocks 180-182 of FIG. 6, the userenters a project name and indicates the storage directory for where theprogram files of test code 54 are to be created. At block 184, the userretrieves the source code file that is to be translated by translator52. In particular, the user selects a first test code 50 thatcorresponds to the circuit card assembly 20 of interest from a memorysource (e.g. computer memory or a removable memory device) and loads theselected first test code 50 into translator 52. In blocks 186-206, thepin configuration of the selected circuit card assembly 20 is enteredinto translator 52. Each pin of circuit card assembly 20 has acorresponding pin number that serves to identify the location of thepins. At block 186, the total number of pins on circuit card assembly 20is entered into translator 52. At block 188, a clock pin of circuit cardassembly 20 is identified and the corresponding pin number is enteredinto translator 52. At block 190, if circuit card assembly 20 includestri-state pins, these tri-state pins are identified and thecorresponding pin numbers are entered into translator 52. A tri-statepin is an output pin that may have a high output, a low output, or anoutput somewhere in between high and low. At block 192, one or moredisabled pins of circuit card assembly 20 are identified and thecorresponding pin numbers are entered into translator 52.

In one embodiment, 120-pin circuit card assemblies 20 may have varyingpower and ground pin locations, while circuit card assemblies with 201pins may have standard power and ground pin locations. At block 194, ifcircuit card assembly 20 does not have 120 pins (i.e., if circuit cardassembly 20 has 201 pins), translator 52 automatically identifies andenters the standard power and ground pins of circuit card assembly 20,as represented by block 198. If circuit card assembly 20 has 120 pins,the location of the power and ground pins are identified, as representedby block 196. If circuit card assembly 20 has special power and groundpins that are not in the standard locations, the location of the powerand ground pins are entered into translator 52, as illustrated by blocks200 and 202. Certain circuit card assemblies 20 may be inserted intoadaptors 38 of test system 30 in an inverted orientation, causing thepins of circuit card assembly 20 to appear to test system 30 asinverted. If circuit card assembly 20 is inserted into test system 30 inan inverted orientation, the pins of circuit card assembly 20 are set intranslator 52 as inverted, as represented by blocks 204 and 206.

In the illustrated embodiment, a user manually enters all informationand input parameters at block 130 of FIG. 5, although translator 52 mayautomatically detect certain pin configurations. In addition, otherinput settings may be entered at block 130 of FIG. 5. For example, theuser may configure translator 52 to generate all program filesassociated with test code 54 or to generate only certain individualprogram files. The input settings may be entered into translator 52 inany suitable order. After all input settings have been entered at block130, the user may initiate the translation process, and translator 52automatically proceeds with blocks 132-158 of FIG. 5.

At block 132 of FIG. 5, all line numbers contained in first test code 50are removed by translator 52. Line numbers are identified and deletedfrom the text in first test code 50 to eliminate errors in the codetranslation. At block 134, translator 52 performs the translation of thefirst test code 50 to the second test code 54, as described herein withreference to FIGS. 7-16.

Referring to FIG. 7, translator 52 first retrieves the first test code50 that was selected at block 184 of FIG. 6. As represented by blocks222, 224, 226, and 228, translator 52 contains an algorithm that stepsthrough each character of each line of code in first test code 50 insearch of special characters. Translator 52 includes a character pointerthat is used to move through each character of first test code 50. Whentranslator 52 reaches the end of a line of code, translator 52immediately moves to the next line of code. When translator 52 hasreached the end of first test code 50, the translation is complete andtranslator 52 returns to block 136 of FIG. 5, as represented by block222 of FIG. 7.

As illustrated in blocks 230-248, translator 52 searches for specialcharacters that trigger additional algorithms used for the translation.In an illustrated embodiment, the special characters identified bytranslator 52 are as follows: “,” (comma), “(” (left parenthesis), “)”(right parenthesis), “<” (open bracket), “>” (close bracket), “+” (plussign), “−” (minus sign), the letter “X”, “:” (colon), and “ ” (space ortab). When one of these characters is found by translator 52, certaintranslation sequences and functions are performed on the characterstrings that are isolated by these special characters, as describedherein.

Several different status flags may be set throughout the translationprocess to control the outcome of various operations. For example, a“function” flag indicates that the translation algorithm is in themiddle of a function call. An “other software” flag indicates thatadditional software (e.g. Fortran) not translatable by translator 52 hasbeen detected and template files must be created for this software, asdescribed herein. A “run pattern” (rp) flag stops the RP( ) functionthat is to be printed after a function is complete. The RP( ) functioninstructs test system 30 to set updated pins without testing theoutputs. The RP( ) function allows many testing steps to be completedprior to verifying the outputs of circuit card assembly 20 with thefunction “TPV”, or test pattern verify, which is described herein. A“high speed” flag is used to flag certain functions, and a “test” flagindicates that a test routine is currently active.

When translator 52 identifies a comma “,”, the “comma identification”routine illustrated in FIG. 8 is run by translator 52, as represented byblocks 230 and 250 of FIG. 7. Commas may be used in first test code 50to separate pin names or to separate statements of code. When used toseparate pin names, the commas are located in the argument portion of afunction statement. At block 280 of FIG. 8, translator 52 firstdetermines if the “function” flag is currently set. The “function” flagindicates that the translation algorithm is in the middle of a functioncall, i.e., that the identified comma is contained within the argumentportion of a function statement. The “function” flag may be set by othersequences throughout the translation process, as described herein. Ifthe “function” flag is set at block 280, all characters preceding theidentified comma but following the last identified special character arestored in a list for later use during the translation process, asrepresented by block 282. For example, in the following exemplary line(1) of first test code 50, the function HI has been called and insidethe brackets is a list of pins separated by commas.

HI<P1,P2,P3>  (1)

As the translation algorithm steps through each character in line (1),the pin names “P1”, “P2”, and “P3” are separately added to the list,allowing translator 52 to generate the corresponding line of second testcode 54 in the proper format. After adding the pin names to the list atblock 282, the “comma identification” routine proceeds to block 284.Alternatively, the “comma identification” routine may end and return tothe translation sequence of FIG. 7 following block 282.

At block 284, translator 52 searches for the character “V” immediatelypreceding the comma to identify the function “TPV”, or test patternverify, contained in first test code 50. The TPV function instructs thetest system to verify that the proper outputs are detected at the outputpins of circuit card assembly 20 following the execution of a testpattern. If the previous character is a “V” at block 284, translator 52initiates the “check function” routine (block 286) illustrated in FIG.9, as described herein. Upon completion of the “check function” routine,translator 52 returns to block 288 of FIG. 8 to close the function. Inparticular, the “check function” routine of block 286 starts a functionby translating the identified function in first test code 50. At block288, the contents of the identified function (e.g., the list of pinnames created in blocks 280 and 282) are added to the translatedfunction, and the translated function is closed (e.g. a closeparenthesis ‘)’ is added to the translated function). For example, usingexemplary line (1) of first test code 50 above, translator 52 creates“HI(” at block 286 and “P1,P2,P3)” at block 288, resulting in a completefunction “HI(P1,P2,P3)” for second test code 54. If the previouscharacter is not a “V” at block 284, the translation algorithmimmediately returns to the translation sequence of FIG. 7 to analyze thenext character in first test code 50.

In the “check function” routine of FIG. 9, translator 52 searches forthe functions defined in first test code 50 and translates them intofunctions to be written into second test code 54. At block 290, if thegroup of characters between the previous special character and thecurrent special character identified by translator 52 matches one of thefunctions of first test code 50, which are provided under “Keyword” inTable 1 below, translator 52 translates the function at block 292. Inaddition, translator 52 returns the corresponding return value providedin Table 1 at block 294. Otherwise, the translation algorithm returns anerror at block 296 indicating that a function was not found in the“check function” routine.

TABLE 1 Function Names and Return Values Keyword: Return: TITLE CompletePROG Complete END Done DISP Complete PAUSE Complete STOP Complete EQUComplete INPUT Complete OUTPUT Complete TEST Test DONE Done RTN ContinueCALL Continue LINK Continue GOTO Continue DO Loop IF Loop HI Function LOFunction INV Function XX Function SEQ Function CNT Function CLK ContinueTOG Function TPV TPV DELAY Continue DASH Continue SYNC Continue HSDLYContinue HSA Continue HSB Continue HSL Continue HSR Continue

The return values in Table 1 direct translator 52 on how to proceed withthe translation. The return values are obtained whenever translator 52runs the “check function” routine of FIG. 9. Translator 52 may handlethe return values by running the “switch” routine illustrated in FIGS.13 and 13A. The “switch” routine directs the translation algorithm basedon the return value obtained from the “check function” routine of FIG.9. Referring to FIG. 13, when the return value is Error (block 350), afunction was not found in the “check function” routine and translator 52is directed to proceed with the translation sequence of FIG. 7. TheContinue return value indicates that the handling of the function iscomplete and directs translator 52 to proceed to the next character infirst test code 50, as represented by blocks 352 and 353. In first testcode 50, two or more functions are sometimes contained in the same lineof code. These functions may return Continue so that translator 52continues to check the same line of code for additional specialcharacters before proceeding to the next line of first test code 50. TheComplete return value directs translator 52 to proceed to the next lineof first test code 50 to continue the translation, as represented byblocks 354 and 366. Functions that stand alone on a single line of firsttest code 50 may return Complete to direct translator 52 to continuesearching for special characters on the next line of first test code 50.

The Function return value sets the “function” flag, as represented byblocks 356 and 368. The functions of first test code 50 that returnFunction each include a list of pins that are usually handled bytranslator 52 and translated properly into the language of second testcode 54. The “close bracket” routine writes this list of pins intosecond test code 54, as illustrated in FIG. 14 and described herein.

Some functions of first test code 50 contain other embedded functions.Referring to block 358 of FIG. 13, the return value of Loop is returnedby these functions. As represented by block 369, the Loop return valueincrements a loop counter that tracks the number of loop functions thathave been called and that indents the next line of code in second testcode 54 according to the number of loop functions that have been called.In addition, translator 52 sets the parenthesis flag to “true” if thenext character is an open parenthesis ‘(’, as represented by blocks 370and 372. Blocks 370 and 372 capture the loops of first test code 50 thatare contained within parentheses. At block 374, the loop counter storesthe maximum value it reaches in a memory. The maximum value of the loopcounter is used by translator 52 to define variables needed for theloops written to second test code 54.

The return values of Test and Done act together in the translationalgorithm. Translator 52 creates a separate test routine in second testcode 54 for each circuit card test routine that is contained in firsttest code 50. See, for example, circuit card test routine 59 of firsttest code 50 in FIG. 2A and test routine 63 of second test code 54illustrated in FIG. 2B. Each test routine in second test code 54 may becalled independently by other code portions of second test code 54,allowing test system 30 to run each test routine independently withouthaving to run all of the test routines. Referring to FIG. 13A, thereturn value of Test at block 360 directs translator 52 to start a newtest routine by setting the “test” flag to true, as represented by block376. If the translation algorithm is currently in the middle of a testroutine (i.e. the “test” flag already is set to true), translator 52ends that test routine first before starting a new test routine, asrepresented by block 375. In addition, the character pointer is adjustedto the next character of first test code 50, as represented by block378. The return value of Done directs translator 52 to end the currenttest routine by setting the “test” flag to false, as represented byblock 386. If a new test routine begins in first test code 50 before afunction is called that returns Done to end the previous test routine,translator 52 records a note in a build log to alert the user. At block388, the character pointer is adjusted to the next character of firsttest code 50.

At blocks 362 and 380, the return value of TPV directs translator 52 todetermine if the next character is an open bracket. In some instances, aTPV function in first test code 50 is immediately followed by anargument in brackets (e.g. TPV<P3,P4>). In other instances, the TPVfunction in first test code 50 stands alone, and translator 52 ends the“switch” routine following block 380. If a left bracket ‘<’ isidentified at block 380, translator 52 creates a TPV (test patternverify) function in second test code 54 which is configured to verifythe current test pattern at block 381. When executed, the TPV functioncreated in second test code 54 directs test system 30 to test the inputand output pins according to the current test pattern and to verify thatthe proper states at the output pins are detected. The TPV return valuealso sets the run pattern “rp” flag at block 382. As described above,the “rp” flag is used to stop the RP( ) function that is to be printedafter a function is complete. At block 384, translator 52 disables thetest pattern.

The return values of Table 1 are occasionally not handled by translator52; i.e., the “switch” routine is not run after every “check function”routine in the translation algorithm. In the illustrated embodiment, theTPV function is the only function in first test code 50 that ends withthe character ‘V’. Whenever translator 52 is searching for the ‘V’character and then runs the “check function” routine, translator 52 willnot handle the return as it assumes that a TPV function will be found.For example, in the “comma identification” routine of FIG. 8, translator52 looks for a specific function preceding the comma in the “checkfunction” routine but does not handle the return value of that functionby calling the “switch” routine. However, in the “open bracket” routineof FIG. 12 described herein, the return values are handled in the“switch” routine immediately after the completion of the “checkfunction” routine.

When translator 52 identifies a left parenthesis “(” at block 232 ofFIG. 7, a parenthesis counter is incremented at block 252. Theparenthesis counter keeps track of all open and close parentheses toidentify when to act on the contents within the parentheses. Whentranslator 52 identifies a right parenthesis “)” at block 234, the“close parenthesis” routine illustrated in FIG. 10 is run by translator52, as represented by block 254. At block 300 of FIG. 10, theparenthesis counter is decremented by one. If the parenthesis counter isless than zero, the parenthesis counter is reset to zero, as representedby blocks 302 and 304. In blocks 306-312, translator 52 acts on thecontents contained within the previous set of parentheses. At block 306,translator 52 checks if the character preceding the special character‘)’ is a “V”, indicating a TPV function is contained within theparentheses. If a “V” is identified, the “check function” routine isagain run by translator 52 at block 308, and the function is closed atblock 310. At block 312, the “check pattern” routine (see FIG. 11) isrun by translator 52 before returning to the translation sequence ofFIG. 7 to analyze the next character of code.

Referring to FIG. 11, the “check pattern” routine places a “run pattern”function into second test code 54. In the illustrated embodiment, therun pattern function is entered into second test code 54 (written in Clanguage) as “RP( )”. When executed, the run pattern function instructstest system 30 to set the input pins according to the test pattern.However, the run pattern function does not instruct test system 30 totest the output pins for correctness (i.e., for the proper outputsignal) based on the set input pins. The run pattern function, whenexecuted by test system 30, allows multiple signal combinations to beintroduced at the inputs and allows these various signals to propagatethrough the circuitry of circuit card assembly 20 before the output pinsare tested by test system 30.

The “check pattern” routine first verifies three conditions: 1) thetranslation algorithm is currently not within any parentheses accordingto the parenthesis counter (block 320); 2) the current circuit card testis not a high speed test (block 322); and 3) the run pattern “rp” flagis enabled (block 324). Test system 30 is configured to run both normalspeed tests and high speed tests on circuit card assembly 20. During ahigh speed test, the run pattern RP( ) functions are not used. If allthree conditions in blocks 320-324 are true, translator 52 places a runpattern RP( ) function in second test code 54, as represented by block326. If any of the three conditions in blocks 320-324 are not true,translator 52 will enable the run pattern “rp” flag and will not place arun pattern RP( ) function in second test code 54.

When translator 52 identifies an open bracket “<” at block 236 of FIG.7, the “open bracket” routine illustrated in FIG. 12 is performed bytranslator 52, as represented by block 256. At block 340, the “bracket”flag is set to indicate to translator 52 that the translation algorithmis currently in the midst of a bracket argument. At block 342, thetranslation algorithm jumps to the “check function” routine of FIG. 9 toidentify the function preceding the open bracket and to return thecorresponding return value. At block 344, translator 52 runs the“switch” routine to handle the return value of the “check function”routine, as described above with reference to FIGS. 13 and 13A.

An open bracket is often followed closely by a close bracket in firsttest code 50. When translator 52 identifies a close bracket “>” at block238 of FIG. 7, the “close bracket” routine illustrated in FIG. 14 isperformed by translator 52, as represented by block 258. The “closebracket” routine actually writes code to second test code 54. At block400 of FIG. 14, translator 52 first checks the function flag. If thefunction flag is set, the values (i.e. pin names) from the list compiledin the “comma” routine of FIG. 8 are written to second test code 54, asrepresented by block 402. Translator 52 closes the function (block 404),clears the list of values (block 406), and clears the function flag(block 408). At block 410, translator 52 jumps to the “check pattern”routine of FIG. 11 to place the run pattern RP( ) function in secondtest code 54 before returning to the translation sequence of FIG. 7.

At block 412, if the loop counter is zero, translator 52 ends the “closebracket” routine. At blocks 412, 414, and 416, if the loop counter isnot zero and the previous character is a “V” (indicating a TPVfunction), translator 52 runs the “check function” routine of FIG. 9 tocheck the previous characters before the last open bracket for afunction. At block 418, if the “check function” sequence returns “TPV”,the function loop is closed at block 420 and the return value is nothandled by translator 52 (i.e. a “switch” routine is not run). At block422, the bracket “}” is written to second test code 54 to indicate theend of the loop. Finally, at block 424, the algorithm decrements theloop counter.

When translator 52 identifies a plus sign “+”, a minus sign “−”, or theletter “X”, the “set” routine illustrated in FIG. 15 is run bytranslator 52, as represented by blocks 240, 242, 244, 260, 262 and 264of FIG. 7. In first test code 50, a plus sign or a minus sign typicallyfollows each pin value. The plus and minus signs are used to set thecorresponding pin of circuit card assembly 20 to a high or low state,respectively. See, for example, the following exemplary line (2) offirst test code 50.

(128+,190+,193−,194−,197−,40—)TPV  (2)

In line (2), pins 128 and 190 are set high and pins 193, 194, 197, and40 are set low. In first test code 50, the ‘X’ value indicates that thecorresponding pin(s) is a tri-state pin and can have a value rangingfrom low to high without causing an error in the test.

Referring to block 440 of FIG. 15, translator 52 checks the previouscharacters of first test code 50 for the word “ALL”. If the word “ALL”is identified, translator 52 writes corresponding code in second testcode 54 configured to set all the pins of circuit card assembly 20 tothe appropriate state (as determined by the ‘+’, ‘−’, or ‘X’ character),as represented by block 442. If the word “ALL” is not identified,translator 52 writes corresponding code in second test code 54configured to set only certain pins (specified in first test code 50) tothe appropriate state in second test code 54, as represented by block444. At block 446, translator 52 runs the “check pattern” routine ofFIG. 11 before continuing with the translation.

When translator 52 identifies a colon “:” at block 246 of FIG. 7,translator 52 starts a new function in second test code 54, asrepresented by block 266. Translator 52 also increments the test numberassociated with the test routine. In one embodiment, translator 52 mayprint comments above the new test routine. If the “test” flag is set atblock 246, translator 52 closes all loops and the current test routinebefore starting a new test routine.

When translator 52 identifies a space or tab “ ”, the “space or tab”routine illustrated in FIG. 16 is run by translator 52, as representedby blocks 248 and 268 of FIG. 7. At block 460 of FIG. 16, translator 52runs the “check function” routine of FIG. 9. Translator 52 runs the“switch” routine of FIG. 13 at block 462 to handle the return value fromthe “check function” routine. At block 464, translator 52 determines ifthe next characters of first test code 50 include more spaces or tabs.Translator 52 skips any multiple spaces or tabs that occur in a row infirst test code 50, as represented by block 466.

Upon completion of the translation in block 134 of FIG. 5, translator 52generates all program files associated with second test code 54 as wellas documentation utilized by test system 30. At blocks 136 and 138,translator 52 generates a project file 137 and a workspace file 139.Project file 137 and workspace file 139 may be run at computer 34 oftest system 30 to open, edit, and/or compile the program filesassociated with second test code 54. In one embodiment, project file 137and workspace file 139 are Labview files configured to run in a Labviewprogram stored at computer 34. At blocks 140 and 142, a main file 141and a main header file 143 are generated by translator 52. Main file 141contains all of the setup and user interface code required to run a teston test system 30. Main header file 143 contains all the declarations.In particular, all functions and global variables are defined in mainheader file 143. In the illustrated embodiment, main file 141 and mainheader file 143 are C files having a .c extension and a .h extension,respectively.

At block 144, a patterns file 145 is created by translator 52. Patternsfile 145 contains the main translation from first test code 50. Inparticular, patterns file 145 contains the actual test code and testroutines run by test system 30 on circuit card assembly 20. For example,FIG. 2B contains an exemplary portion (e.g. test routine 63) of patternsfile 145. At block 146, a functions file 147 is created by translator52. Functions file 147 contains the hybrid functions that are called bypatterns file 145, as described above with reference to FIG. 3. In theillustrated embodiment, patterns file 145 and functions file 147 are Cfiles having .c extensions.

At block 148, first pinmap document 114, described above with referenceto FIG. 4, is created by translator 52. In the illustrated embodiment,first pinmap document 114 is a header file in C language having a .hextension. First pinmap document 114 contains the definitions of thepinmap including which pins of circuit card assembly 20 are power orground pins and which pins of circuit card assembly 20 are normal inputand output pins.

At block 150, translator 52 determines if an additional software testcode was utilized by the legacy test system. If yes, translator 52creates template files 153 and 155 at blocks 152 and 154, respectively.As discussed above with reference to FIG. 2, template files 153 and 155are software code templates configured to receive program code manuallyinput by a user or automatically input by another program or systemfollowing the translation by translator 52. For example, if first testcode 50 references software functions written in Fortran language,template files 153 and 155 define these Fortran functions. In oneembodiment, template file 153 is a main file with a .c extension thatcontains the translated Fortran functions called by first test code 50.In one embodiment, template file 155 is a header file with a .hextension that contains the translated Fortran function prototypesneeded by the compiler of second test code 54. If translator 52 is notconfigured to translate Fortran language code, the user provides thetranslations of the Fortran software code to template files 153 and 155.

At block 156, translator 52 generates second pinmap document 116, asdescribed above with reference to FIG. 4. In the illustrated embodiment,second pinmap document 116 is a spreadsheet document, such as a commaseparated value (.csv) file for example, that contains all the pin namesand bus definitions for second test code 54 that runs on test system 30.This file is imported into computer 34 to interface with software 60 sothat software 60 displays the proper pin names of circuit card assembly20 to user interface 32.

At block 158, translator 52 generates a readme file 159 that contains adescription of the files created by translator 52. In particular, readmefile 159 may be a text file containing various instructions, notes, andcomments regarding the program files created by translator 52.

In one embodiment, once second test code 54 has been created bytranslator 52, the user may open and compile second test code 54 atcomputer 34 of test system 30. In another embodiment, computer 34generates an output file that contains the compiled test program. Theuser runs the compiled test program to perform the test on circuit cardassembly 20 at test system 30.

While this invention has been described as having an exemplary design,the present invention may be further modified within the spirit andscope of this disclosure. This application is therefore intended tocover any variations, uses, or adaptations of the invention using itsgeneral principles. Further, this application is intended to cover suchdepartures from the present disclosure as come within known or customarypractice in the art to which this invention pertains.

1. A software translation method comprising the steps of: receiving a first software code containing a first function command and data associated with the first function command, the first function command being configured to produce a first result; associating at least one second function command in a second software code with the first function command; and generating a third software code based on the first software code, the generating step including: creating a hybrid function command based on the first function command, the hybrid function command including an interface to the at least one second function command of the second software code; and creating a case statement configured to associate the first function command of the first software code with the hybrid function command and to provide the data associated with the first function command to the hybrid function command, the hybrid function command being configured to produce the same first result as the first function command upon execution of the hybrid function command using the data associated with the first function command of the first software code provided by the case statement; wherein said first function command and said hybrid function command comprises a function name description and parameter list, wherein said first function command's function name description and said hybrid command's function name description are comprised of identical function name descriptions; wherein the third software code includes a first program file containing the case statement and a second program file containing the hybrid function command.
 2. (canceled)
 3. The software translation method of claim 1, wherein the first software code is in a first computer language and the second software code and the third software code are in a second computer language.
 4. The software translation method of claim 1, wherein the first software code is a test code utilized by a first test system for performing an operational test on a circuit card assembly and the second and third software codes are test codes utilized by a second test system for performing the operational test on the circuit card assembly, wherein the first result produced by the first function command and the hybrid function command includes at least one test operation of the operational test on the circuit card assembly.
 5. The software translation method of claim 4, wherein the second software code is an instrument code file configured to interact with testing instruments of the second test system to execute the at least one test operation on the circuit card assembly.
 6. The software translation method of claim 5, wherein the associating step includes identifying at least one second function command in the second software code that is configured to cause the testing instruments of the second test system to perform at least a portion of the at least one test operation on the circuit card assembly.
 7. The software translation method of claim 6, wherein the data associated with the first function includes the identification of at least one pin of the circuit card assembly, the at least one test operation being performed on the at least one pin of the circuit card assembly. 8-16. (canceled)
 17. A software translation system comprising: a first non-transitory machine readable medium section comprising a plurality of machine readable instructions comprising first software code containing a first function command and data associated with the first function command, the first function command being configured to produce a first result; a second non-transitory machine readable medium section comprising a plurality of machine readable instructions comprising second software code containing at least one second function command; and a third non-transitory machine readable medium section comprising a plurality of machine readable instructions comprising translator configured to receive the first software code and to generate a fourth non-transitory machine readable medium section comprising a plurality of machine readable instructions including a third software code based on the first software code, the third software code including a hybrid function command including an interface to the at least one second function command of the second software code and a case statement associating the first function command of the first software code with the hybrid function command and being configured to provide the data associated with the first function command to the hybrid function command, the hybrid function command being configured to produce the same first result as the first function command upon execution of the hybrid function command using the data associated with the first function command of the first software code provided by the case statement; wherein said first function command and said hybrid function command comprises a function name and parameter list, wherein said first function command's function name and said hybrid command's function name are comprised of identical function name descriptions; wherein the third software code includes a first program file containing the case statement and a second program file containing the hybrid function command.
 18. (canceled)
 19. The software translation system of claim 17, wherein the translator is an executable computer program.
 20. The software translation system of claim 17, wherein the first software code is a test code written in a first computer language utilized by a first test system for performing an operational test on a circuit card assembly and the second and third software codes are test codes written in a second computer language utilized by a second test system for performing the operational test on the circuit card assembly, wherein the first result produced by the first function command and the hybrid function command includes at least one test operation of the operational test on the circuit card assembly.
 21. The software translation system of claim 20, wherein the second software code is an instrument code file configured to interact with testing instruments of the second test system to execute the at least one test operation on the circuit card assembly.
 22. The software translation system of claim 21, wherein the second software code is stored in a memory of a computer of the second test system.
 23. The software translation system of claim 21, wherein the at least one second function command in the second software code is configured to cause the testing instruments of the second test system to perform at least a portion of the at least one test operation on the circuit card assembly.
 24. The software translation system of claim 23, wherein the data associated with the first function includes the identification of at least one pin of the circuit card assembly, the at least one test operation being performed on the at least one pin of the circuit card assembly. 25-31. (canceled) 